Managed medical information exchange

ABSTRACT

A managed medical information exchange system is disclosed. In an example, an exchange system is configured to manage medical information by redacting a portion of medical records. The medical information may have patient identifying information and/or protected health information (PHI) removed therefrom prior to being stored in a shareable data portion for access by users. Further still, the medical information in the shareable data portion may be formatted according to an identity of a user accessing the data, a context in which the data is to be used, and/or a requested format of the data. In turn, the exchange of medical information may facilitate data analytics that may serve a variety of beneficial purposes.

PRIORITY CLAIM

This application claims priority to and the benefit as a continuationapplication of U.S. patent application Ser. No. 14/753,712, filed onJune 29, 2015, entitled “MANAGED MEDICAL INFORMATION EXCHANGE”, whichclaims priority to U.S. Provisional Application No. 62/019,227, filed onJun. 30, 2014, entitled “MANAGED MEDICAL INFORMATION EXCHANGE”, theentire contents each of which are incorporated herein by reference andrelied upon.

BACKGROUND

Many healthcare facilities utilize pharmacy resources to preparemedication preparations that are to be administered to a patient. Suchpharmacy resources may be located locally at the healthcare facility ormay be remote from the healthcare facility. In either regard, medicationpreparations at the pharmacy resource may be prepared in response toreceipt of a medication dose order. Such medication dose orders may be,in at least some instances, patient-specific dose orders that aregenerated by a healthcare professional and correspond to a request forpreparation of the medication preparation to be prepared foradministration to the patient. In other applications, the dose ordersmay be stock orders or non-patient-specific.

Many healthcare facilities generate records corresponding to dose ordersthat are prepared by a pharmacy resource. The records may includeinformation received with the medical dose order and/or information thatmay be added to the record by the pharmacy resource (e.g., includingdetails about the products and/or preparation used to prepare the dosecorresponding to the medical dose order). Such records may be storedand/or used locally at the pharmacy resource for a variety of potentialpurposes including for example, regulatory compliance, patient safety,inventory management, staffing decisions, or other purposes related tothe management of the pharmacy resource and/or medication preparations.

Furthermore, continued developments in communication technology andcollaborative tools increasingly make it easier to share and access datain a networked environment (e.g., through software services, datasharing platforms, or other network connectivity sometimes collectivelyreferred to as “cloud services”). However, medical information (e.g.,including dose order records or the like) may be subjected to accessand/or dissemination restrictions. For example, access to such data maybe limited to access by appropriate personnel at the healthcare facilityor pharmacy resource. For instance, in the United States the HealthInsurance Portability and Accountability Act (HIPAA) provides regulatoryrequirements regarding the handling, dissemination, or other privacyrelated aspects of medical records that may contain protected healthinformation (PHI). In this regard, the use, dissemination, and/or accessto dose order records, and especially patient-specific dose orderrecords that may include PHI may be limited by regulatory complianceand/or other privacy concerns. As such, despite the benefits that may beprovided with the ability to collaboratively share data for applicationof cloud services thereto, limits on the use of data may limit theaccess to such valuable data.

Furthermore, systems used to maintain and/or generate medicalinformation may be proprietary, such that specific data formats areutilized. Thus data exchange may be limited by data formattinglimitations. For instance, data generated or stored in a proprietaryformat specific to a first entity may not be readable by another entity.

SUMMARY

The present disclosure relates to systems and methods that facilitatecollaborative approaches to the management of information, particularly,information related to medication preparation information received inrelation to provision of medical care. In this regard, the presentdisclosure relates to managed exchange of medical information. Theexchange of medical information may be improved by use of selectiveredaction and/or formatting of the medical information. For example, toallow for increased exchange of medical information that may includepatient identifying information or protected health information (PHI),certain data of the medical information may be redacted. Furthermore, acryptographic hash function may be applied that reliably transforms aportion of information (e.g., information related to patient identifier)into a non-identifying value. In turn, records may still be associatedwith a given patient while the patient's PHI and/or patient identifyinginformation may be removed.

Furthermore, given the potentially wide array of data analytics that maybe applied to medical information exchanged using the descriptionpresented herein, the data may be formatted prior to access by users ofa data exchange platform to facilitate specific data analytics. This mayinclude a standardized format that is common to all users of the systemand/or particularized formats corresponding to particular users,particular uses of the data, and/or particular types of data. In anyregard, the use of an exchange platform as described herein mayfacilitate improved access to data to allow for more expanded, robust,and efficient data analytics in a number of contexts. In particular,inter-party exchange of data may be improved through data formattingrules associated with a collaboration system described herein. As such,data analytics may be expanded as data from a plurality of sources maybe utilized and provided in a format. For example, data analyticsrelated to multiple, inter-party data sources may be facilitated by thedisclosure presented herein may help improve patient safety (e.g., byidentifying potentially harmful trends with a collection of data),provide business intelligence, assist in reducing the cost ofhealthcare, or other meaningful benefits.

Accordingly, a first aspect includes a system for exchange ofinformation related to patient-specific medication preparations. Thesystem includes a data storage device in operative communication withone or more healthcare facilities to receive, from the one or morehealthcare facilities, information regarding patient-specific medicationpreparations prepared at corresponding respective ones of the one ormore healthcare facilities. In embodiments, the medical information mayalso include non-patient specific data received from one or moreadditional sources. The data storage device includes a sharable dataportion that stores redacted data records having patient identifying(e.g., protected health information (PHI)) removed therefrom. Theredacted records correspond to the information regarding medicationpreparations that is received from the one or more healthcarefacilities. The system also includes a collaboration module that is inoperative communication with the data storage device. The collaborationmodule is operative to access the shareable data portion to extract datafrom the shareable data portion, transform the extracted data into adata format based at least in part on a predetermined operational need,and load the formatted data into a remotely accessible data storagelocation that is accessible remotely from the data storage device. Inthis regard, the predetermined operational need may be based on anidentified data analysis to be performed, an identity of a partyaccessing the data, a requested format by a party accessing the data, orsome other particular purpose for the data.

A number of feature refinements and additional features are applicableto the first aspect. These feature refinements and additional featuresmay be used individually or in any combination.

As such, each of the following features that will be discussed may be,but are not required to be, used with any other feature or combinationof features of the first aspect.

For example, the PHI may include a patient identifier. Furthermore, thesystem of the first aspect may facilitate removal of patient identifyinginformation, while still allowing an association between data recordsand a given patient. As such, one or more of the redacted data recordsstored in the shareable data portion may also comprise a uniqueidentifier that associates one or more portions of the informationregarding medication preparations to a given patient without providingidentifying characteristics relative to the patient. The uniqueidentifier may include a hash value generated in response to applicationof a hash function to the patient identifier.

The hash function may be executed by a processor at the data storagedevice to generate the redacted data records that are stored in theshareable data portion. Alternatively, a hash function may be executedlocally at the one or more healthcare facilities to remove patientidentifying information prior to providing the data to the data storagedevice. Accordingly, the system may receive medical information that hasbeen redacted at a data source. As such, the hash function may beexecuted by a processor at the one or more healthcare facilities togenerate the redacted data records that are received at the centralstorage server for storage in the sharable data portion. In anembodiment, the hash value may include a deterministic, non-invertablevalue based on the patient identifier. That is, for each given uniquepatient identifier used to generate a has value, a corresponding uniquehash value is generated. Furthermore, a user may not be able toascertain the plain text patient identifier using only the hashfunction.

In an embodiment, the data storage device may also include a backup dataportion that comprises complete data records (i.e., that potentiallyincludes PHI) corresponding to at least a portion of the informationregarding medication preparations received from the one or morehealthcare facilities. The backup data portion and the shareable dataportion may be separately accessible on the data storage device. Thatis, users who access the shareable data portion may not have access tothe backup data portion. The collaboration module may provide aplurality of users selective and secure access to the shareable dataportion based on a plurality of security layers applied to access theshareable data portion.

In an embodiment, the data format in which the collaboration moduleprovides the redacted data may include a standardized data formataccessible by the plurality of users. The data format may include aplurality of distinct data formats. As such, different ones of theplurality of distinct data formats may be accessible by correspondingdifferent respective ones of the plurality of users.

In an embodiment, the data storage device may include a data storageserver located remotely from the one or more healthcare facilities.Specifically, the data storage device may comprise a plurality ofmirrored data servers distributed at distinct geographic locations. Assuch, redundancy may be provided such that the likelihood of data lossat both of the distributed data servers is reduced.

In an embodiment, the system of the first aspect may be used inconnection with the ordering, preparation, and/or administration of adose to a patient. As such, the information regarding medicationpreparations may include dose order records generated in response toreceived dose orders for mediation preparations to be administered to apatient.

The system of the first aspect may also include an analytics module inoperative communication with the data storage location to retrieve theformatted data. In turn, the analytics module may be operative toperform at least one analysis on the information regarding medicationpreparations in relation to a specific given patient without theparticular identity of the specific given patient. The analysisperformed by the data analytics module may at least include analysiswith respect to the unique patient identifier. For instance, dosesadministered to a given patient may be analyzed.

Other analysis may be facilitated or conducted without limitation.Examples of such analysis may include error tracking in relation to oneor more given dose order data fields. Accordingly, tracked errors may beexamined to determine if a common data parameter exists to facilitate aroot cause investigation. For example, high error rates with respect todoses prepared with a given drug or medical product may allow forunderlying causes (e.g., a potential confusing label or the like) to beidentified with respect to the given drug or medical product.

Further still, data analysis may be facilitated or performed to helpparameterize and evaluate a supply chain related to the manufacture,ordering, preparation, distribution, and/or administration of a dose. Inthis regard, as data related to a given dose, including medical productinformation used in the preparation of the dose, may be provided to thesystem, inventory tracking and supply chain evaluation may be conductedat any one or more portions of the supply chain from, for example, amedical product manufacturer to, for example, dose administration. Suchanalysis may be at least partially based on one or more dose order datafields contained in the medical information received at the system.

In an embodiment, the information regarding medication preparations maybe received at the data storage device in accord with a local datapolicy of each respective one of the one or more healthcare facilities.As such and as stated above, patient identifying information may beremoved from the medical information prior to the receipt of the data atthe system of the first aspect. The removal of such patient identifiersmay be at least in part based on the local data policy of eachrespective healthcare facility. The local data policy may beconfigurable for each respective one of the healthcare-facilities.

A second aspect includes a method for generation of shareableinformation regarding patient-specific medication preparations. Themethod includes receiving, from one or more healthcare facilities,information regarding patient-specific medication preparations preparedat corresponding respective ones of the one or more healthcarefacilities for administration to a patient. The method further includesstoring the information as a shareable data portion stored on a datastorage device in the form of redacted data records that correspond tothe information regarding patient-specific medication preparations thatis received from the one or more healthcare facilities. The redactedrecords have patient identifying information (e.g., protected healthcareinformation (PHI)) removed therefrom. The method further includesformatting the redacted data records to a format corresponding with apredetermined operational need and loading the formatted data into aremotely accessible storage location for access by users remote from thestorage location.

A number of feature refinements and additional features are applicableto the second aspect. These feature refinements and additional featuresmay be used individually or in any combination. As such, each of thefollowing features that will be discussed may be, but are not requiredto be, used with any other feature or combination of features of thesecond aspect. Furthermore, any one or more of the feature refinementsand additional features described above in relation to the first aspectmay be, but are not required to be, used with the second aspect.

For instance, in an embodiment, the PHI may include at least a patientidentifier. The method may further include associating a uniqueidentifier with one or more of the redacted data records thatcorresponds to a given patient and does not provide identifyingcapability relative to the patient. As such, the storing may furtherinclude applying a hash function to the patient identifier andgenerating the unique identifier in response to the applying. The uniqueidentifier may, in turn, comprise a hash value resulting from theapplying.

In an embodiment, the method may further include providing a pluralityof users selective and secure access to the redacted data records. Forinstance, to access the redacted data records, a user may be required toundergo a plurality of security layers that may require provision ofauthentication information.

In an embodiment, the formatting may include formatting the redacteddata records to a standardized format accessible by the plurality ofusers. Additionally or alternatively, the formatting may includeformatting the redacted data records to a plurality of distinct dataformats. The different ones of the plurality of distinct data formatsmay be accessible by corresponding different respective ones of theplurality of users.

In an embodiment, the method may further include generating theinformation regarding medication preparations comprise dose orderrecords in response to received dose orders for mediation preparationsto be administered to a patient. The method may also include accessingthe data storage location to retrieve the formatted data and analyzingthe information regarding medication preparations in relation to aspecific given patient without the particular identity of the specificgiven patient. The method may include performing any one or more of thetypes of analysis described above in relation to the first aspect.

Additionally, the method may further include that the receiving theinformation regarding medication preparations is at least partiallybased on a local data policy of each respective one of the one or morehealthcare facilities. As such and as described above, a local datapolicy may be enforced at the healthcare facility.

While the foregoing has referenced receiving medical information from ahealthcare facility, the foregoing system and method aspects may also beutilized to receive medical information from any one or more of aplurality of data sources. Such data sources may include pharmaceuticalmanufacturers that manufacture drug products or medical products (e.g.,that may be used in the preparation of a dose). The data sources mayalso include hospital information systems. Hospital information systemsmay provide data related to inventory tracking of medical productsreceived and/or distributed throughout a facility. The hospitalinformation systems may also provide medical information includingmedical records or the like. Additional data sources may include, forexample, information from medical device operational databases (e.g.,including administration devices such as infusion pumps) and/ordispensing cabinets. Furthermore, any one or more of the data sourcesmay, but are not required to, access data for purposes of performingdata analytics or the like. Accordingly, data analytics on aggregateddata received from a number of sources may be facilitated. In thisregard, data originating from a plurality of sources in connection withthe manufacture, ordering, preparation, and/or administration of a dosemay be aggregated to provide a wider array of analytical options inrelation to the data. The improved access to such aggregated, redacted,and formatted data may facilitate improvements in a number of contextsincluding patient safety, pharmacy efficiency, business development,inventory management, and others.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic view of an embodiment of a system for exchange ofinformation related to medication preparations.

FIG. 2 is a schematic view of an embodiment of a system for exchange ofinformation related to medication preparations.

FIG. 3 is a schematic view of an embodiment of a collaboration platformwith collaborative data analytics relative to shared information relatedto medication preparations.

FIG. 4 is a flow chart depicting an embodiment of a method for exchangeof information related to medication preparations.

FIG. 5 is a schematic view of an embodiment of an implementation of acollaboration platform for exchange of medical information in aparticular context including dose preparation and administration.

DETAILED DESCRIPTION

The following description is not intended to limit the invention to theforms disclosed herein. Consequently, variations and modificationscommensurate with the following teachings, skill and knowledge of therelevant art, are within the scope of the present invention. Theembodiments described herein are further intended to explain modes knownof practicing the invention and to enable others skilled in the art toutilize the invention in such, or other embodiments and with variousmodifications required by the particular applications(s) or use(s) ofthe present invention.

The present disclosure generally relates to the exchange of medicalinformation, and especially to the management of the exchange of medicalinformation that may include dose order records related to medicationpreparations prepared for administration to a patient for the purpose ofproviding data analytics relative to the medical information. Theexchange of such medical information may facilitate a data collaborationplatform that enables various entities to perform data analytics on themedical information that may originate from a plurality of data sourcesfor a variety of purposed including, for example, to improve patientsafety, to track medical trends, to obtain business intelligence, or forother purposes related to the medical information.

Different entities may have the incentive and/or know-how to providedifferent kinds of analytics. Accordingly, the present disclosurefacilitates a collaboration platform that enables widespread sharing ofdata to a plurality of parties that may each provide data analytics. Inturn, providing a data collaboration platform that provides collectedand/or aggregated data in an appropriate format to a plurality ofpotentially unrelated parties may facilitate improved data analyticsbased on the variety of providers that may access and/or analyze theformatted data that is provided by the platform.

Accordingly, the platform may be facilitated by a collaboration systemthat includes at least one data storage device comprising a backup dataportion and a shareable data portion. The collaboration system mayfurther include a collaboration module. In this regard, thecollaboration system may receive medical information from plurality ofdata sources. Additionally, the collaboration system may provide accessto a plurality of users that access the collaboration system and receivedata (e.g., for the purpose of performing data analytics). A partycomprising a data source may additionally comprise a party that accessesthe collaboration system to access data for the purpose of dataanalytics. That is, a party (e.g., an individual user, a corporate user,a governmental user, or the like) providing data to the collaborationsystem may further retrieve data from the collaboration system thatincludes the data supplied by the party and/or data from other partiesthat has been aggregated.

A particular concern regarding exchange of medical information includesmaintaining the privacy of patients as it relates to the exchange ofmedical information. For instance, medical information may includepatient identifying information (e.g., potentially including protectedhealth information (PHI)). In this regard, dissemination of medicalinformation may subject to restrictions due to regulatory issues (e.g.,the Health Insurance Portability and Accountability Act (HIPAA) in theUnited States may prohibit dissemination of medical information withPHI) or other privacy concerns. Accordingly, the embodiments describedherein may be operative to redact medical information to remove patientidentifying information (e.g., PHI) from the data.

While removal of PHI or other patient identifying information may benecessary prior to dissemination of medical information for compliancewith regulations such as HIPAA or for other privacy factors, it maystill be beneficial to associate related medical records to a givenpatient, even if the identity of a patient is not provided. Forinstance, if a patient named “Jane Doe” may have a number of medicalinformation records associated with her. The present disclosurefacilitates redaction of those medical information records by use of aunique identifier. For instance, Jane Doe's medical records may beassociated with “Patient X,” where Patient X is non-identifying of JaneDoe. As such, some data analytics may benefit from a non-identifyingassociation between medical records and a given patient (e.g., analyticsthat relate to trends relative to given patients or analytics thatrelate to correlations with specific patients). For purposes of theseanalytics, simply identifying related medical records for a givenpatient, even in the absence of identifying information regarding thepatient may be beneficial. As such, the embodiments described herein mayprovide such a unique identifier that may associate medical informationfor a given patient, but not provide any patient identifyinginformation. For instance, a patient identifier may be used as an inputto a one-way cryptographic hash function that generates a hash valuethat may comprise the unique identifier. In this regard, each uniquepatient identifier may result in a corresponding unique hash value thatdoes not identify the patient when input to the hash function. As such,the unique identifier (e.g., the hash value) may be used to associatemedical information to a given patient without providing patientidentification.

As such, a collaboration platform facilitated by the embodiments hereinmay generate and/or store redacted medical information. A collaborationplatform may further provide access to formatted data generated fromredacted data records to facilitate data analytics. In turn, the formatprovided may be a standardized format that is common to all users or mayinclude specialized or particular formats (e.g., proprietary formats)that are based on a user, application, or other criteria. In any regard,the platform described herein including the system and methods describedbelow facilitate improved data sharing to promote application of cloudservices and other data analytics to medical information for a varietyof purposes.

FIG. 1 depicts an embodiment of a system 100 that facilitates exchangeof medical information. In an application, the medical information mayinclude information regarding medication preparations prepared inresponse to a dose order. For example, a healthcare facility 110 mayutilize a local or remote pharmacy resource that is capable of preparinga medication preparation (also referred to herein as a dose) foradministration to a patient. In this regard, a plurality of healthcarefacilities 110 a, 110 b, and 110 c may be in operative communicationwith a data storage device 120. While three healthcare facilities 110a-110 c are depicted in FIG. 1, fewer or more healthcare facilities 110may be in operative communication with the data storage device 120without limitation.

The healthcare facilities 110 a-110 c depicted in FIG. 1 may correspondto any appropriate healthcare facility 110 that generates, stores,supplements, or accesses medical information. Accordingly, thehealthcare facilities 110 may include but are not limited to hospitals,pharmacies, outpatient care providers, home care providers, or the like.In any regard, the information provided to the data storage device 120may include any medical information. In an embodiment, the medicalinformation may relate to medication preparations such as doses to beadministered to a patient that are prepared in response to a dose order.In a particular embodiment, the medical information may includepatient-specific records corresponding to medication preparations (i.e.,doses) that the healthcare facility 110 prepared and/or requested to beprepared for administration to a patient. As such, the healthcarefacilities 110 may have access to pharmacy resources that may beutilized to prepare medications for administration to a patient. Accessto pharmacy resources may include use of a local pharmacy located at thehealthcare facility or use of remote pharmacy that provides medicalinformation (e.g., dose order records) and medication preparations tothe healthcare facility 110. For example, at least a portion of thehealthcare facilities 110 may include hospital facilities that mayinclude local pharmacy resources that generate dose order records inresponse to receipt of dose orders that correspond to requestedmedication preparations.

In this regard, the healthcare facility 110 may utilize a pharmacyworkflow manager to generate and/or supplement the medical informationthat is to be provided to the data storage device 120. This pharmacyworkflow manager may include any or all details as described in U.S.application Ser. No. 14/022,415, which is incorporated by reference inits entirety. An example of one such pharmacy workflow manager mayinclude the DoseEdge™ pharmacy workflow manager offered by BaxterHealthcare Corporation of Deerfield, Ill. In this regard, the healthcarefacility 110 may employ a tool that may capture dose order informationto generate and/or supplement dose order records corresponding to a doseto be prepared for administration to the patient. This may includecapturing dose order data received from an order entry system and/orsupplementing the dose order record with dose order metadata regardingthe dose to be prepared and/or the preparation of the dose. As describedin greater detail below, the dose order records may comprise medicalinformation that may be provided to the data storage device 120.

In turn, the data storage device 120 may be operative to store theinformation regarding the medication preparations such as, for example,dose order records received from the healthcare facility 110. In thisregard, the healthcare facility 110 may provide a dose order record thatcorresponds to a dose order received from a healthcare provider. Oneexample may be a dose order record generated in response to a providergenerating a dose order that is received at a pharmacy for a medicationdose to be administered to a patient. Upon receipt of the dose order,the healthcare facility 110 may generate a dose order recordcorresponding to the dose order.

The dose order record may contain one or more dose order record datafields. The dose order record data fields may be populated with doseorder metadata related to the dose order. The dose order metadata may beobtained from a received dose order (e.g., by way of a dose order entrysystem or the like) or may be associated with the dose order afterreceipt of the dose order (e.g., by a pharmacy workflow manager or thelike during the management, preparation, and/or distribution of the dosecorresponding to the dose order). The dose order record data fields mayinclude one or more fields that provide patient identifying information.For instance, the dose order record data fields may include data relatedto a patient name, geographic data, pertinent dates (e.g., date ofbirth, date of admission, date of administration, etc.), telephonenumbers, fax numbers, email addresses, social security numbers, medicalrecord numbers, health plan beneficiary numbers, account numbers,certificate/license numbers, vehicle identifiers and serial numbersincluding license plate numbers, device identifiers and serial numbers,uniform resource locators (URLs), Internet protocol addresses, biometricidentifiers (i.e. retinal scan, fingerprints), identifying images, orany unique identifying number, characteristic or code. The patientidentifier may, in this regard, comprise PHI that is associated with adose order record.

Other potential dose order record data fields may also be provided thatrelate to the generation, preparation, distribution, and/oradministration of the dose. For instance, such dose order record datafields may include, for instance, a scheduled drug administrationdate/time, an actual drug administration date/time, a scheduleddistribution date/time, an actual distribution date/time, an expirationdate for the medication preparation, a dilution value, a count of thenumber of medical products in the dose, a date/time of entry of the doseorder, a volume measure of the dose, a date/time of the first dose of aseries of doses, an indicator as to whether the dose is a first dose ina series of doses, an indicator of whether the dose comprises hazardousmaterials, an indicator of whether the dose is a high risk dose, a doseidentifier, an indication of whether the dose is a test dose, a labelformat for a label corresponding to the dose, a nursing unitcorresponding to the dose, order instructions, whether the dose order ison hold, a date/time for when the dose order is to be on hold, anoverfill amount for the dose, a basal energy expenditure value for apatient, a body surface area value for a patient, a patient height, apatient weight, a duration for how long a dose is pending, a date/timethe dose was prepared, whether a label for the dose order has beenprinted, at what time the dose order label was printed, the name of theprinter to which the dose order label was printed, a rate ofadministration of the dose, an indication of whether the dose was everrejected by a pharmacist during preparation, a date/time the dose wasrejected, the identity of the pharmacist that rejected the dose, anadministration route for the dose, a history of scan events for thedose, a date/time of scan events for the dose, a date/time the dose wassorted, an indication of the dose status, an indication of whether thedose was a stock dose, whether the dose was for total parenteralnutrition (TPN), an indication of the type of TPN associated with thedose, a date/time the dose was verified by a pharmacist, an identify ofwho verified the dose, an indication of who performed a given steprelated to the dose, dose preparation documentation (e.g., includingimages of the dose preparation and/or product preparation for componentsof the dose order), an error log for the dose or other appropriateinformation related to the dose. In an embodiment, the dose order recordincluding any one or more of the fields described above may be providedto the data storage device 120.

The data storage device 120 may be located remotely from each healthcarefacility 110 with which the data storage device 120 is in communication.In an embodiment, the information received at the data storage device120 may be a complete data record received from a healthcare facility110. A complete data record may refer to a data record that contains thesame information when received at the data storage device 120 as wascontained by the data record at the healthcare facility 110. That is, acomplete data record may have no data redacted therefrom. Theinformation received at the data storage device 120 may be dose orderrecords with information related to one or more dose order record fieldsas described above. Accordingly, the data storage device 120 may thusstore a backup copy of the records provided from each respectivehealthcare facility 110. That is, complete copies of dose order recordsfrom the healthcare facility 110 may be provided to and stored on thedata storage device 120. Accordingly, the data storage device 120 mayinclude a backup portion 130 that stores the complete data records(e.g., dose order records) received from each respective one of thehealthcare facilities 110. As may be appreciated, data provided by thehealthcare facilities 110 may be in a proprietary data format that mayor may not be readable by third parties without use of correspondingproprietary software executed by the healthcare facility 110.

In an embodiment, the backup data portion 130 may be operative toprovide a backup version of data to any one or more of the healthcarefacilities 110. For instance, in the event of a data loss at any one ormore of the healthcare facilities 110 a-110c, the backup data portion130 may be able to provide a backup copy of a database to the healthcarefacility 110 for the purposes of restoring the database. That is, dataprovided from any respecting one of the healthcare facilities 110 may beprovided back to the given healthcare facility 110 as a data backup. Assuch, provision of the medical information by the healthcare facilities110 may provide the facilities 110 benefit in the form of a data backup.Thus, medical information that relates to patient health may beefficiently backed up at the backup data portion 130 and available forrestoration at the healthcare facility 110 in the event of a data lossat the facility 110.

The data storage device 120 may also include a shareable data portion150. The shareable data portion 150 may store data records that have atleast a portion of the medical information redacted therefrom. Forexample, in an embodiment, records in the shareable data portion 150 mayhave personal health information (PHI) removed therefrom. In thisregard, a data screening module 140 may be provided. The data screeningmodule 140 may access the complete data records stored in the backupdata portion 130. The data screening module 140 may remove one or moreportions of data (e.g., PHI or other patient identifying information)from the records. In turn, the redacted data records may be stored inthe shareable data portion 150.

As such, the backup data portion 130 and the shareable data portion 150may be separated such that access to each respective data portion may becontrolled. While the data portions may reside on the same device (e.g.,a common drive, server, or the like), the data portions may besegregated such that access on one portion may not allow for access tothe other. In an embodiment, the data portions may be stored ondifferent corresponding devices.

It may be advantageous to provide associations between the data recordscorrespond to a given patient even if the given patient is notidentified (i.e., even if the records are redacted). Thus, the system100 may be operative to associate redacted records and a patient todetermine what medication preparations were associated with a givenpatient without providing information that identifies the actualpatient. As the identity of the patient may comprise PHI, the identityof the patient may be redacted from the record while still providing anassociative relationship between all records for a given patient. Thatis, the data screening module 140 may generate a unique identifier thatcorresponds to a given patient but is not capable of identifying thepatient. As such, all data records associated with that patient may beassigned the unique identifier corresponding to the patient. All datarecords for the given patient may therefore be identified while theidentity of the patient themselves may not be provided.

One example of a unique identifier may comprise a hash value generatedby application of a cryptographic hash function to one or more portionsof the complete data record prior to storing the redacted record in theshareable portion 150. In turn, the redacted data records may be storedwith a generated hash value, which may comprise a unique identifier. Inan embodiment, the complete dose record may include one or more patientidentifier. For instance, the dose records may include field containingthe patient name and/or other identifying information related to thepatient such as, for example, a facility identifier for the patient, adate of birth, a social security number, or other patient identifyinginformation as described above. Accordingly, the patient identifier mayinclude PHI. In turn, any one or more of the patient identifiers of thecomplete dose record may comprise an input to the hash function. Theresulting hash value output may provide the unique identifier that maybe stored in corresponding relation to the redacted data records storedin the shareable data portion 150.

The data screening module 140 may apply a hash function to one or morepatient identifier fields of the complete dose order records. Forinstance, one or more cryptographic hash functions may be applied suchas, for example, SHA-1, SHA-2, SHA-3, MDS, RIPEMD-128/256, RIPEMD-320,RTR0, or other appropriate hash functions now existing or laterdeveloped. Preferably, the applied hash function is deterministic. Thatis, for each given unique input a corresponding unique output isprovided by the function without data collisions. Furthermore, the hashfunction is preferably non-invertable. For example, when provided with ahash value resulting from the hash function, the input that resulted inthe hash value should not be ascertainable. Thus, the hash functionpreferably provides a one-way conversion of the patient identifier to anon-identifying unique value that is unique for each given one of aplurality of patients. In turn, the unique value for a given patient maybe the same each time the hash function is applied. Thus, two or moredifferent dose order records associated with a given patient may bothreceive the same unique identifier upon application of the hash functionto the records. As such, a review of the resulting redacted dose orderrecords containing the unique identifier in place of a patientidentifier may allow for dose order records corresponding to a givenpatient may be identified based on a common unique value (e.g., a hashvalue). The hash value may also be further encoded, e.g. using Base64encoding on the resulting hash value.

The system 100 may also include a collaboration module 160. Thecollaboration module 160 may access the shareable data portion 150containing the redacted data records. In turn, the collaboration module160 may retrieve the redacted data records for transformation into aformat that may be useable by one or more remote users 170 and/or localusers 165 of the system 100. The format into which the collaborationmodule 160 transforms the redacted data may be at least partially basedon a predetermined operational need of the local user 165 or remote user170 that requests the data from the collaboration module 160.

The collaboration module 160 may facilitate selective, secure access tolocal users 165 and/or remote users 170 who wish to access the formatteddata extracted by the collaboration module 160 from the shareable dataportion 150. In this regard, a plurality of access layers may beprovided that must be satisfied by users prior to accessing theformatted data from the shareable data portion 150. For instance, theremote user 170 may be required to access a first layer such as avirtualized private network (VPN) or the like. Accessing the VPN mayrequire a remote user 170 to provide appropriate credentials (e.g., avalid user name and password combination, a cryptographic key, aone-time password, a biometric value, etc.). A local user 165 may berequired to be utilizing an access terminal on a common network with thecollaboration module 160 (e.g., a local area network or the like). Auser may then access the collaboration module 160 with furthercredentials (e.g., a valid user name and password, a cryptographic key,a one-time password, a biometric value, etc.). Once the user has joinedthe VPN or accessed the collaboration module 160 on a common network andprovided the necessary credentials to access the collaboration module160, the user may have access to the formatted data at the collaborationmodule 160 based on the redacted data records in the shareable dataportion 150. As such, a plurality of access layers may be provided toreduce unauthorized access to the shareable data portion 150.

The collaboration module 160 may access the redacted data records in theshareable data portion 150 and extract the data therefrom. In turn, thecollaboration module 160 may transform the data into a given format thatis loaded (e.g., to a storage device at the collaboration module 160and/or in the shareable data portion 150) for access by users 165/170.The format of the data may comprise a standardized format. Thestandardized format may in turn be accessible by all those who accessthe collaboration module 160. The standardized format may include anextensible markup language (XML) format. The standardized format mayadditionally or alternatively be provided as a delineated text file, apivot table, or any other standardized format or data view. In thisregard, data that may be provided in a proprietary format (e.g., asdescribed above) may in turn be formatted such that the data may beaccessed and/or viewed by other parties/users that are incapable ofviewing the data in the proprietary format provided. As such, the datamay be more widely disseminated to provide further data analyticsrelative thereto.

In an embodiment, the collaboration module 160 may format the redacteddata from the shareable data portion 150 into a format at least in partbased on the user who is to access the data, an application in which thedata is to be used, a requested format of the user, and/or otherappropriate criteria. For instance, different remote users 170 may haveaccess to the collaboration module. As described above, access to thecollaboration module 160 by a remote user 170 may include one or morelayers of access protocols that require authentication including, forexample, providing a user name and password. In this regard, access tothe collaboration module 160 may at least in part identify the remoteuser 170 accessing the collaboration module 160. In this regard, theformat of the data to which a remote user 170 has access may at leastdepend on the identity of the user 170. For instance, a first remoteuser 170 may be associated with a first party and receive the formatteddata in a first format associated with the first party (e.g., aproprietary data format corresponding to the first party). A secondremote user may be associated with a second party and receive theformatted data in a second format associated with the second party (e.g.a proprietary format associated with the second party). The first andsecond formats may be different and may be unique to the particular useraccessing the collaboration module 160. As will be described in greaterdetail below, different remote users 170 of the formatted data providedby the collaboration module 160 may have different operational needs asit relates to the data stored in the shareable data portion 150. Assuch, the format of the data presented to a user 165/170 may be based onan anticipated use of the data and/or a requested format by the user165/170.

As may be appreciated in FIG. 1, the data storage module 120 andcollaboration module 160 may collectively comprise a collaborationsystem 305. In this regard, the healthcare facilities 110 a-110 c maycomprise data sources that provide data to the collaboration system 305.In turn, users 170 and/or 165 may access the data provided by the datasources 110 a-110 c by utilizing the collaboration system 305. In thisregard, the embodiment depicted in FIG. 1 provides one exemplaryembodiment of a collaboration system 305, however as will be appreciatedin further reference to FIG. 2 below, other embodiments of collaborationsystems 305 are contemplated.

Furthermore, the various components depicted in FIG. 1 may be inoperative communication over one or more networks. That is, the variousmodules and devices depicted may each be in operative, networkedcommunication. The network communications may utilize a wide areanetwork such as the Internet or the like. Additionally or alternatively,the communications may be by way of one or more local area networks,intranets, private networks, or the like. Furthermore, the modules anddevices may comprise integrated systems or may be provided discretely.For instance, in an embodiment, the data storage device 120 may includediscrete hardware for each of the backup data portion 130 and theshareable data portion 150. For instance, each respective data portionmay be provided on separate hardware such as separate hard drives,separate servers, or the like. Alternatively the portions may comprisesegregated data spaces on a common device such as a common hard drive, acommon server, or the like. In this same regard, the data screeningmodule 140 and/or collaboration module 160 may each be stand alonemodules executing on discrete hardware devices or either module may beexecuted on a common hardware device that may or may not also containthe backup data portion 130 and/or the shareable data portion 150.

FIG. 2 depicts another embodiment of a system 200 for exchange ofinformation. The variations and details described above in relation toFIG. 1 may be applicable to the system 200 of FIG. 2 unless specifiedotherwise. The system 200 generally includes healthcare facilities 210 aand 210 b that are in operative communication with a primary datastorage device 222. The primary storage device 222 may be in operativecommunication with a secondary or backup data storage device 224. Inturn, a datamart module 260 may be in operative communication with thebackup data storage device 224. Remote users 270 may access the datamartmodule 260. In turn, medical information received from the healthcarefacilities 210 a and 210 b may be selectively provided to the remoteusers 270 for advantageous data analytics relative thereto.

As shown in FIG. 2, each healthcare facility 210 may include a backupservices module 212. The backup services module 212 may be in operativecommunication with one or more local database of the healthcarefacility. For instance, the backup service module 212 at the healthcarefacility 210 a may be in operative communication with local databases214 and 216. In this regard, local databases 214 and 216 may storeinformation at the healthcare facility 210 a. Backup service 212 athealthcare facility 210 b may be in operative communication with a localdatabase 218 at healthcare facility 210 b. In an embodiment and asdescribed above, the information may include dose order recordscorresponding to dose orders for medication preparations to beadministered to a patient.

In any regard, the backup service module 212 may access a local databaseat the healthcare provider 210 and provide information to the primarydata storage device 222. The backup service module 212 may periodicallypoll the one or more databases with which it is in operativecommunication and provide any new or modified records to the primarydata storage device 222. Alternatively, the backup service module 212may continuously monitor one or more database and provide records to theprimary data storage 232 in a real time or near real time basis.

The backup service module 212 may also apply a local backup policyestablished by each respective healthcare facility 210. For instance, ahealthcare facility 210 may wish not to provide information containingcertain data fields (e.g., those fields corresponding to patientidentifiers and/or PHI) to the primary data storage device 232. In thiscase, the backup service 212 may facilitate redaction of one or moreportions of the data from the data prior to providing the data to theprimary data storage device 232. In an embodiment, the backup servicemodule 212 may be operative to generate a unique identifiercorresponding with a given patient as was discussed above in connectionwith the data screening module 140. That is, the backup service module212 may locally generate a unique value that uniquely associates a givenpatient with one or more data records, yet is non-identifying of thepatient. As such, the backup service 212 may be operative to apply ahash function to the data records to redact a patient identifier fromthe records. In turn, the information provided from the backup service212 to the primary data storage device 222 may include a uniqueidentifier in lieu of patient identifying information.

The primary data storage device 222 may include a backup data portion232 at the primary data storage device 222. The primary data storagedevice 222 may also be in operative communication with a backup datastorage device 224. The backup data storage device 224 may include abackup data portion 234. The backup data portion 232 of the primary datastorage device 222 may be replicated and stored in the backup dataportion 234 of the backup data storage device 224. The primary datastorage device 222 and the backup data storage device 224 may bedistributed at distinct geographic locations. For example, the primarydata storage device 222 may be located at a first geographic location onthe east coast of the United States and the backup data portion 224 maybe located at a second geographic location on the west coast of theUnited States. Periodically, the primary data storage device 222 maycommunicate data from the backup data portion 232 to the backup dataportion 234 of the backup data storage device 224. As such, a backup ofthe backup data portion 234 may be stored at each location. Accordingly,the use of geographically distributed storage device locations mayreduce the potential for data loss at both facilities simultaneously.Thus, in addition to the primary data storage device 222 facilitatingdata backup services for the healthcare facilities 210, a further backuppotential is created by use of the backup data storage device 224. Assuch, in the event of a data loss at a healthcare facility 210 and/orthe primary data storage device 222, the backup data storage device 224may provide backup copies of data to the facility 210 and/or primarydata storage device 222 to facilitate data recovery.

The backup data storage device 224 may include a data screening module240. Although, the data screening module 240 could be located at theprimary data storage device 224 in addition to or as an alternative tothe backup data storage device 224 without limitation. In either regard,the operation of the data screening module 240 would be the same. Asdescribed in relation to FIG. 1, the data screening module 240 maygenerate a unique identifier associated with a patient identifier forthe purpose of redacting a portion of the data records (e.g. includingpatient identifiers and/or PHI) to be stored in a shareable data portion250 at the backup data storage device 224. In the embodiment depicted inFIG. 2, data records may be provided in a redacted form from the backupservice module 212 at the healthcare facility. In this regard, the datascreening module 240 may further redact the data records or pass thepreviously redacted records on to the shareable data portion 250. In anyregard, the information stored in the shareable data portion 250 may beredacted (e.g., the data may have patient identifiers and/or PHI removedtherefrom).

The shareable data portion 250 may be in operative communication with acollaboration module 262. The collaboration module 262 may be providedin a datamart module 260. The datamart module may allow for thecollaboration module 262 to extract, transform (e.g., format), and loadformatted data into a datamart storage device 264 for access by remoteusers 270. Again, the formatted data may be provided in a standardizedform or may be provided in particular given forms accessible by theremote users 270 as discussed above.

In this regard, FIG. 2 depicts another embodiment of a collaborationsystem 305 the comprises the primary data storage device 222, the backupdata storage device 224 and the data more module 260. In this regard,collaboration system 305 may include geographically remote backup datastorage devices for the purpose of providing additional data redundancy.In this regard, the healthcare facilities 210 a and 210 b may comprisedata sources that provide medical information to the collaborationsystem 305. In turn, the collaboration system 305 may provide access tothe redacted and formatted medical information to remote users 270.

FIG. 3 depicts a schematic view of an embodiment of a collaborationplatform 300 that may be used to provide medical information from one ormore data sources to users for the purpose of facilitating dataanalytics on the medical information. The collaboration platform 300 mayinclude a collaboration system 305. The collaboration system 305 maycomprise a system such as collaboration system 305 described above inrelation to system 100 shown in FIG. 1 or collaboration system 305 shownin FIG. 2. In any regard, the collaboration system 305 may receiveinformation from a healthcare facility 310. In turn, the information maybe provided in a shareable data portion of the collaboration system 305for access by users such that the information received from thehealthcare facilities 310 is transformed prior to access by one or morethird parties. For instance, the transformation may include redactingpatient identifiers and/or PHI from the data and/or transforming thedata into a format useful to users of the system 305.

However, the collaboration system 305 may also be in operativecommunication with one or more other sources of data in addition or asan alternative to the healthcare facilities 310. For instance, thecollaboration system 300 may be in operative communication with amedical device operational database (e.g., a dose administration devicedatabase or other appropriate source of medical device information), ahospital information system 314, external pharmacy resources 316, and/orany other appropriate source of medical information. In the event themedical information received from the data source (e.g., the healthcarefacility 310, the medical device operational database, the hospitalinformation system 314, the external pharmacy resources 316 and/or anyother appropriate source of medical information) contains information tobe redacted (e.g., patient identifiers and/or PHI), the collaborationsystem 305 may be operative to redact the medication information and,for instance, generate a unique identifier that is related to, but doesnot identify a patient as described above.

The collaboration system 305 may provide access to formatted datagenerated from one or more data sources. The data provided by thecollaboration system 305 may include redacted data records with patientidentifiers and/or PHI removed therefrom regardless of the source of thedata. The data provided by the collaboration system 305 may also beformatted as described above in relation to the embodiments ofcollaboration modules discussed above. The collaboration system 305 maythus format data from a plurality of sources that may originate indifferent formats. As such, the collaboration system 305 may beoperative to combine and/or aggregate data from the different sourcesfor presentation to users in a standard or particular format.

The collaboration system 305 may, thus, aggregate and format a largeamount of medical data from a plurality of sources. In turn, users mayaccess the aggregated and formatted data of the collaboration system305. Such users may be local users 320 that locally access thecollaboration system 305 (e.g., are users on a common network with thecollaboration system 305 such as users of a local area network,intranet, or the like). Thus, internal analytics within a givenorganization may be facilitated. Furthermore, external users 330 mayaccess the collaboration system 305 (e.g., users that access the system305 by way of a wide area network or the like). In turn, internalanalytic users 320 and/or external service providers 330 may have accessto the collaboration system 305. The format available to and/oraccessible by different users may depend upon the user's identity,whether the user is an internal or external user, and/or a given purposefor which the user is accessing the data.

The modules described herein may comprise software, hardware, or acombination of both. For instance, the modules of the system may includespecifically configured hardware such as application specific integratedcircuits (ASICs), programmable field gate arrays, or other appropriateprocessors. In an embodiment, the modules may include a microprocessorin operative communication with a memory. The memory may comprise anon-transitory computer readable medium that may includemachine-readable instructions. As such, the processor may access thememory and be specifically configured by the machine-readableinstructions stored therein to execute any of the functionalitydescribed herein. Additionally, the modules described above may beexecuted using a common processor in operative communication with amemory that provides the functionality of a plurality of modules. Inthis regard, the modules may be executed using a single common processoror different modules may be executed using different processors.

Turning to FIG. 4, an embodiment of a method 400 for exchange of medicalinformation by way of a collaboration platform is depicted in the formof flow chart. The method may include collecting 402 information fromone or more data sources. As described above, the data sources fromwhich medical information is collected may include healthcarefacilities, medical device operational databases, hospital informationsystems, external pharmacy resources, or any other appropriate sourcesof medical information. In turn, the method 400 may include storing 404medical information in a backup data portion. As described above, theshareable data portion may comprise a portion of a data storage device.

In an embodiment, the method 400 may include creating 406 backup datarecords. The back of data records may comprise a copy of completerecords stored in the backup data portion. The backup data records maybe stored in a remote geographic location separate from the backup dataportion stored in step 404. In turn, the backup data records may be usedto restore lost or corrupted data at a healthcare facility and/or otherdata source.

The method 400 may also include accessing 408 the complete medicalinformation (e.g., the complete data records). As described above, itmay be beneficial to redact a portion of the complete data records to,for example, remove patient identifying information therefrom. In thisregard, the method 400 may include redacting 410 one or more portions ofinformation from the medical records accessed at step 408. As describedabove, the redacting 410 may include applying a hash function togenerate hash value based at least in part on a portion of the datarecords including, for example, a patient identifier and/or PHI. Themethod 400, in turn, includes storing 412 the redacted medicalinformation in a shareable data portion. The shareable data portion maybe separate from the backup data portion such that selective access toeither portion may be separately facilitated.

In an embodiment, the method 400 includes extracting 414 the redactedrecords from the shareable data portion. The method 400 may furtherinclude formatting 416 redact data records into a data format that maybe useful to a user accessing the redacted records (e.g., for purposesof data analytics). In this regard, the format may be standardizedformat presented all users of the system or may be particularly directedto a particular user and/or data analytic context for which the data isto be used. The method 400 may further include loading 418 the formattedredacted records (e.g., by a collaboration module or the like) tofacilitate access to the formatted redacted records. In turn, the method400 may include permitting 420 selective, secure access to the formattedredacted data records by users of the platform. As described above, theusers may each have access to a standardized format or may be presentedwith a specific format of data based on the identity user, and indicatedapplication for which the data is to be used, or a requested format typeby the user.

In turn, the medical information collected 402 from the various sourcesof medical information may be transformed and made available to users toperform, for example, data analytics on the medical information.Accordingly, the method 400 may include performing 422 data analyticswith respect to the formatted redacted records there selectivelyaccessed 420. Examples data analytics may include, for example,monitoring trends with respect to ordered doses for the purpose ofimproving patient safety relative to the ordered doses and/or improvingbusiness opportunities by gaining actionable business intelligence datarelative to the activities corresponding to the medical informationgained from the one or more sources. Other data analytics may becontemplated such as those described in greater detail below. In thisregard, the data analytics may be provided in the form of the pluralityof services by users may access and/or perform data analytics on theredacted, formatted medical information in a cloud architecture (e.g.,using networked resources) to facilitate improved efficiency, speed,and/or utilization of resources relative thereto.

FIG. 5 depicts an embodiment of a platform 500 utilizes a collaborationsystem 305 aggregate data in turn provide redacted formatted data to oneor more users who in turn access the data. As such, the collaborationsystem 305 may comprise a collaboration system according to theembodiment of a collaboration system 305 depicted in FIG. 1 and/orembodiment of a collaboration system 305 depicted in FIG. 2.Furthermore, any other appropriate combination of modules, components,or other devices comprising a collaboration system 305 and provided thatfacilitates redaction and formatting of medical information providedfrom one or more sources. In this regard, collaboration system 305 mayinclude additional or fewer modules than those described with respect tothe specific embodiments described in FIGS. 1 and 2. As such, theembodiments depicted in FIG. 1 and FIG. 2 are exemplary, but notlimiting.

In FIG. 5, the collaboration system 305 is discussed in relation to thecontext of preparation of a dose for a patient. In this regard, thesolid arrow lines in FIG. 5 may represent flow of physical goods betweenthe various entities described. The dash-dot lines in FIG. 5 representflow data between the various entities in the collaboration system 305.Accordingly, the platform 500 shown in FIG. 5 represents one particularapplication of a collaboration system 305 is a relates to the flow ofmaterials in connection with preparation and administration of the doseto the patient and healthcare facility.

The platform 500 may include a pharmaceutical manufacturer 510. Thepharmaceutical manufacturer 510 may manufacture a medical product of adose such as a drug compound and/or other intermediaries includingdiluents or the like. Accordingly, the pharmaceutical manufacturer 510may provide the manufactured medical product to a hospital that employsa hospital information system 512. Specifically, an inventory managementsystem at a healthcare facility may be executed by the hospitalinformation system 512 may allow for receipt and tracking of goods fromthe pharmaceutical manufacturer 510.

The pharmaceutical manufacturer 510 may also provide data to thecollaboration system 305. In this regard, the pharmaceuticalmanufacturer 510 may comprise a data source that provides medicalinformation collaboration system 305. Examples of pertinent data thatthe pharmaceutical manufacturer 510 may provided the collaborationsystem 305 may include for example, medical product identifiers, lotnumbers, expiration dates, inventory management numbers, productconcentrations, product sizes, or other information related to medicalproducts manufactured by the pharmaceutical manufacturer 510.

The inventory management component of the hospital information system512 may, after receipt of medical products from the pharmaceuticalmanufacturer 510, monitor the medical products including, for example attime in which a medical product is requested at a pharmacy and/or trackinformation associated with medical products including, for example lotnumbers, expiration dates, product identifiers, or the like. As such, apharmacy workflow manager 514 may be provided in the pharmacy of ahealthcare facility. The pharmacy workflow manager 514 may receiveproducts from the inventory management system of the hospitalinformation system 512. For instance, the pharmacy workflow manager 514may request medical products for use in preparation of doses from theinventory management system 512. As such, inventory management system512 may facilitate provision of medical products to the pharmacy fortracking by the pharmacy workflow manager 514.

The inventory management portion of the hospital information system 512may also provide data to the collaboration system 305. Exemplary datamay include, for example, average inventory levels, current inventorylevels, inventory supply parameters including average durations amedical product is maintained in stock prior utilization, and/or dataconcerning the movement of medical products within a hospital including,for example, provision of drug products to the pharmacy workflow manager514 for use in preparation of a dose.

The pharmacy workflow manager 514 may facilitate preparation of dosesfor administration to patients. As described above, the preparation ofdoses may be in response to received dose orders from healthcareproviders or the like. As such, the pharmacy workflow manager 514 mayreceive dose order information as described above. Furthermore, thepharmacy workflow manager 514 may supplement such data with informationrelated to the preparation of the dose. For example, images may becaptured related to the medical product(s) utilized to prepare the dose.Furthermore, data may be gathered from medical products and used topopulate specific dose order records corresponding to a dose order. Thedose order may or may not be patient specific. In this regard, the doseorder record may include information regarding a lot number or anexpiration date of a medical product used to prepare the dose.Additionally, the pharmacy workflow manager 514 may supplement data suchas the identity of the pharmacy technician who prepared the dose, thepharmacist who approved the dose, as well as parameters related theretosuch as the time/date when such events occurred. Furthermore, thepharmacy workflow manager 514 may present to a pharmacy technician aprotocol for use in preparation of the dose. The specific protocolutilized may also be associated with the dose order record.

The pharmacy workflow manager 514 may also provide data to thecollaboration system 305. In this regard, the one or more portions ofthe data described above that is the generated and/or received by thepharmacy workflow manager 514 may be provided. In this regard, thepharmacy workflow manager 514 may provide information related to thepreparation of a dose and/or related to the medical product(s) used toprepare the dose. Furthermore, the data provided by the pharmacyworkflow manager 514 to the collaboration system 305 may includeinformation related to the time/date at which certain events relative tothe dose order occur. The pharmacy workflow manager 514 may also detecterrors that occur during the preparation of the dose order. For example,a pharmacy technician may scan an incorrect medical product to be usedin connection with the dose to be prepared. While the pharmacy workflowmanager 514 may alert the pharmacy technician of the error such that itmay rectified, the pharmacy workflow manager 514 may further record theperformance of the error in connection with the dose order with which itoccurred.

The pharmacy workflow manager 514, upon dispensation of a dose from thepharmacy, may provide the dose to a dose dispensing cabinet 516. Thedose dispensing cabinet 516 may be accessible by patients, healthcarefacility personnel, or others to retrieve a dose once prepared. Thisregard, the dose dispensing cabinet 516 may track and/or collect certaininformation related to the dose. Examples of such data may include thetime a dose is placed or retrieved in the dispensing cabinet 516 priorto retrieval, the identity of a person stocking and/or retrieving a dosefrom the dose dispensing cabinet 516, number of available doses in thedispensing cabinet 516, the number of free storage areas in the dosedispensing cabinet 516, or other relevant data. The dose dispensing 516may also track errors related to the retrieval of dose orders from thedose dispensing 516. For example, unauthorized attempts to accessstorage location may be recorded. Furthermore, erroneous attempts toaccess storage location or attempt to access the incorrect storylocation may also be tracked. As such, any or all the data collected oravailable to the dose dispensing cabinet 516 may also be provided to thecollaboration system 305.

Once the dose is retrieved from the dose dispensing cabinet 516, thedose may be administered to a patient using an administration device518. That is, healthcare facility personnel such as a nurse or the likemay retrieve a dose from the dose dispensing cabinet 516. The dose mayin turn be connected to an administration device 518. The administrationdevice 518 may, for example, be an infusion pump utilized to deliver thedose to a patient. In this regard, the administration device 518 mayrecord information regarding the dose administered such as, the patientto which the doses administered, or other relevant information such asthe time of administration, parameters regarding the administration(e.g., administration rate, administration duration, etc.), or otherinformation collected regarding the administration of the dose. Theadministration device 518 may further provide any such information ithas access to or generates to the collaboration system 305.

Once doses are delivered to a patient, a patient record portion of ahospital information system 520 may be updated to record theadministration of the dose to the patient. For example, parameters suchas the hospital personnel responsible for the administration of thedose, the time/date of the dose, or other relevant medical recordinformation including health care provider notes or the like be recordedin the patient records of the hospital information system 520.Furthermore, this information may also be provided to the collaborationsystem 305. The administration device 518 may further track errors. Forexample, the administration device 518 may include checks to ensureproper programming of the administration device 518. In the event thatan improper programming is made, the error may be recorded byadministration device 518.

Accordingly, the collaboration system 305 may collect information fromthe various stages related to the manufacture, preparation, and/oradministration of the dose to the patient. As described above, thecollaboration system 305 may aggregate, redact, and format such data. Inturn, the collaboration module of the collaboration system 305 may allowaccess to the aggregated, redacted, and formatted data for purposes ofdata analytics. As briefly stated above, it may be valuable for thesources of data (e.g. any one or more of the entities described in FIG.5) to not only provide data to collaboration system 305, but alsoretrieve data from the collaboration system 305 for a number ofdifferent reasons. As may be appreciated in FIG. 5, the entities shownmay not only provided to collaboration system 305 may also each compriseusers that in turn have access to the collaboration system 305 to accessthe aggregated, redacted, and formatted data. In this regard, by virtuethe collaboration system 305 providing redaction and formatting, any oneor more of the entities shown in FIG. 5 may have access to a shareabledata portion of the collaboration system 305 to gain access to data foruse in data analytics.

This may open the available data to each one of the specific entitiesbeyond that for which they are solely responsible. That is, thepharmaceutical manufacturer 510 may access the collaboration system 305to obtain data related to the hospital information system 512 and/or520, a pharmacy workflow manager 514, a dose dispensing cabinet 516, oran administration device 518. Absent the collaboration system 305, thecollection in or use of such data may be arduous at each individual oneof the entity shown in FIG. 5 may be required to solicit informationdirectly from other entities and be subjected to concern such as dataprivacy and security. However, the collaboration system 305 may providea central aggregation, redaction, and formatting of a pool of shareddata that in turn provides efficient access to data for purposes thedata analytics beyond that available for each individual entities onportion of the data supplied to collaboration system 305.

Some relevant examples of data analytics that made performed utilizingthe platform 500 shown in FIG. 5 may include analysis that provides forimproved patient safety, medical results, inventory management, businessinsight, security, or other useful outcomes related to the dataanalysis. For example and as described above, errors may be tracked atone or more the pharmacy workflow manager 514, dose dispensing cabinet516, or administration device 518. In an effort to improve patientsafety, a pharmaceutical manufacturer 510 may review data provided bythe collaboration system 305. As the data aggregated by thecollaboration system 305 may provide insights to the occurrence oferrors with respect to a number of parameters including a particularmedical product utilized to prepare the dose, the pharmaceuticalmanufacturer 510 may determine if error rates at any one or more of thepharmacy workflow manager 514, dose dispensing 516, or administrationdevice 518 are more prevalent with a particular medical product.Identification of such trends may in turn allow the pharmaceuticalmanufacturer 510 to determine a root cause of a source of the error andremedy the root cause. For example, in the pharmacy workflow manager514, confusing labeling of packaging may result in an increased errorrate with respect to a particular medical product. In turn, thepharmaceutical manufacturer 510 may identify the increased error ratewith respect to the medical product and in turn launch a root causeanalysis. In turn, a source of the error in the form of the confusinglabeling may allow the pharmaceutical manufacturer 510 to improve thelabeling and reduce the errors associated with the medical product.

Similarly, one or more of the entities in FIG. 5 may be interested inanalytics with respect to inventory for purposes of improvingsupply-chain characteristics at any one or more portions of the supplychain between the pharmaceutical manufacturer and the administration ofthe dose to the patient. For example, the data provided by thecollaboration system 305 allow for analytics with respect to turnaroundtimes, throughput of doses, cycle times, or the like. Furthermore,information provided the various sources of data may allow for analysiswith respect to the best source doses. For example, a pharmacy workflowmanager 514 may determine, based on data analyzed from the collaborationsystem 305, whether it is more efficient to produce a dose within thepharmacy or, for example, buy premade doses from an outside vendor.Furthermore, an entity responsible for a dose dispensing cabinet 516 mayutilize data retrieved the collaboration system 305 determine whetherdiversion a product from the dose dispensing cabinet is occurring.

In this regard, number of valuable parameters contained within the dataprovided by the collaboration system 305 may be leveraged to provideuseful insights during data analytics. Specifically, given the foregoingdiscussion regarding the de-identifying of medical information whilepreserving the ability to associate various portions of the medicalinformation with a given patient, patient specific analysis may beundertaken. This may be useful for providing insight regardingadministration of doses to particular patient. For example, the delaybetween dose order entry and dose administration may be examined withrespect particular patients. In turn, correlations with respect to typesof medication, administration routes of medication, the nursing unitassociated with the doses, or even facilities in general, can be made.That is, metrics with regard to these various parameters may be examinedin connection with delays between dose order and administration toprovide increases in efficiency for the process of preparing andadministering the doses to a patient. Such may be particularly valuablein urgent or “STAT” doses with the understanding that the timesensitivities associated with such doses may be critical to patientoutcomes in certain instances such as an emergency context.

While the invention has been illustrated and described in detail in thedrawings and foregoing description, such illustration and description isto be considered as exemplary and not restrictive in character. Forexample, certain embodiments described hereinabove may be combinablewith other described embodiments and/or arranged in other ways (e.g.,process elements may be performed in other sequences). Accordingly, itshould be understood that only the preferred embodiment and variantsthereof have been shown and described and that all changes andmodifications that come within the spirit of the invention are desiredto be protected.

What is claimed is:
 1. A system for an exchange of information relatedto dose preparation, the system comprising: a data storage device inoperative communication with a plurality of healthcare facilities,wherein the data storage device is configured to receive, from theplurality of healthcare facilities, information regarding a plurality ofdose preparations prepared at the plurality of healthcare facilities,wherein the data storage device comprises (i) a sharable data portionthat stores redacted data records for each of the plurality of dosepreparations having patient identifying information removed therefrom,and (ii) a backup data portion that stores data records for each of theplurality of dose preparations including the patient identifyinginformation, and wherein the sharable data portion is configured to havea first access control and the backup data portion is configured to havea different, second access control to prevent cross-access between thesharable data portion and the backup data portion; and a processor thatis in operative communication with the data storage device, theprocessor configured to perform a cryptographic operation on the patientidentifying information to create unique hash values, create redacteddata records storing the unique hash values instead of the patientidentifying information, and store the redacted data records to thesharable data portion.
 2. The system of claim 1, wherein the patientidentifying information comprises protected health information (PHI)that at least comprises a patient identifier.
 3. The system of claim 2,wherein each of the unique hash values includes a unique identifier thatassociates one or more portions of the information regarding therespective patient without providing identifying characteristicsrelative to the patient.
 4. The system of claim 3, wherein the uniqueidentifier comprises the first unique hash value that is generated inresponse to the application of the cryptographic operation to thepatient identifier.
 5. The system of claim 1, wherein the processor ispart of the data storage device for generating the redacted data recordsthat are stored in the shareable data portion.
 6. The system of claim 1,wherein the processor is located at the plurality of healthcarefacilities for generating the redacted data records that are received atthe data storage device for storage in the sharable data portion.
 7. Thesystem of claim 1, wherein each of the unique hash values comprises adeterministic, non-invertable value based on the patient identifier. 8.The system of claim 1, wherein the backup data portion comprisescomplete data records including the patient identifying informationcorresponding to at least a portion of the information regarding theplurality of dose preparations received from the plurality of healthcarefacilities.
 9. The system of claim 8, wherein the backup data portionand the shareable data portion are separately accessible on the datastorage device.
 10. The system of claim 1, further comprising acollaboration module configured to provide a plurality of usersselective and secure access to the shareable data portion based on aplurality of security layers applied to access the shareable dataportion.
 11. The system of claim 1, wherein the data storage devicecomprises a data storage server located remotely from the plurality ofhealthcare facilities.
 12. The system of claim 1, wherein the datastorage device comprises a plurality of mirrored data serversdistributed at distinct geographic locations.
 13. The system of claim 1,wherein the information regarding the plurality of dose preparationscomprises dose order records generated in response to received doseorders for the plurality of dose preparations to be administered. 14.The system of claim 1, wherein the information regarding the pluralityof dose preparations is received at the data storage device inaccordance with a local data policy of each respective one of theplurality of healthcare facilities.
 15. A method for generatingshareable information regarding dose preparation, the method comprising:receiving, from a plurality of healthcare facilities, informationregarding a plurality of dose preparations prepared at the plurality ofhealthcare facilities; storing the information as a backup data portionstored on a data storage device in the form of data records for each ofthe plurality of dose preparations including patient identifyinginformation; storing the information as a shareable data portion storedon the data storage device in the form of redacted data records for eachof the plurality of dose preparations having the patient identifyinginformation removed therefrom; configuring a first access control forthe sharable data portion and configuring a different, second accesscontrol for the backup data portion to prevent cross-access between thesharable data portion and the backup data portion; performing, via aprocessor, a cryptographic operation on the patient identifyinginformation to create unique hash values; storing, via the processor tothe data storage device, a unique hash value to each of the redacteddata records instead of the patient identifying information; andloading, via the processor, the redacted data records into a remotelyaccessible storage location for access by users remote from the remotelyaccessible storage location.
 16. The method of claim 15, wherein thepatient identifying information comprises protected health information(PHI) that comprises at least a patient identifier.
 17. The method ofclaim 15, wherein the storing further comprises generating the uniqueidentifier in response to applying the cryptographic operation to thepatient identifier.
 18. The method of claim 15, further comprisingproviding a plurality of users selective and secure access to theredacted data records.
 19. The method of claim 15, further comprisinganalyzing the redacted data records without the particular identity ofthe respective patients, wherein the analyzing comprises at least one oferror analysis, inventory management, or supply chain management. 20.The method of claim 15, wherein receiving the information regarding theplurality of dose preparations is at least partially based on a localdata policy of each respective one of the plurality of healthcarefacilities.